Como remover o Relé

MEV-Boost é o protocolo sidecar atual na blockchain Ethereum para extrair MEV, dependendo fortemente de participantes centralizados chamados Relé. Propusemos uma arquitetura alternativa que permite comunicação direta e criptograficamente privada entre construtores e proponentes. Essa arquitetura é baseada em uma forma inovadora de encriptação de limiar não interativa 'silenciosa', que pode usar as Chave Secreta BLS existentes dos validadores.

Essencialmente, propomos o uso de encriptação em bloco de limiar, enviando-o para um subconjunto de participantes para alcançar privacidade e disponibilidade de dados através de um comité de prova. Suas provas formam uma chave de desencriptação; assim que o limiar desejado for alcançado, o bloco pode ser desencriptado.

A nossa solução de construção aborda a questão da privacidade entre os construtores e os proponentes, mas por si só não pode garantir a eficácia do Bloco. Pode ser combinada com outros mecanismos para replicar integralmente as funcionalidades fornecidas pelo Relé, incluindo a privacidade e a eficácia do Bloco. Por exemplo, pode-se recorrer a Provas de Execução Confiável (TEE) ou Provas de Conhecimento Zero (ZK), ou através de um mecanismo económico de encriptação para garantir os construtores.

Ao eliminar a necessidade de privacidade dos construtores de Relé e garantir a validade dos Blocos, nosso objetivo é reduzir a latência, aumentar a descentralização e a resistência à censura do Ethereum.

O papel do MEV-Boost e do Relé

MEV-Boost é um intermediário de protocolo de lado, atuando como intermediário entre construtores de Bloco e proponentes. O papel principal do Relé é fornecer duas garantias: [funções de relé hoje] (https://ethresear.ch/t/relays-in-a-post-epbs-world/16278#h-2-relay-roles-today-3)

Privacidade do construtor: O Relé garante que os proponentes não possam ver o conteúdo do Bloco nem roubar o MEV encontrado pelo construtor.
Segurança do proponente: O Relé garante que o construtor pague ao proponente o valor prometido de acordo com o lance e garante que o Bloco seja válido (por exemplo, todos os pagamentos de transação cobrem o gás interno).

No entanto, a dependência do Relé introduz uma centralização significativa. Cerca de 90% dos blocos da cadeia de blocos ETH são transmitidos por apenas algumas entidades Relé. Isso traz vários riscos:

Centralização: Os construtores podem melhorar a eficiência de latência através da implantação conjunta com Relé, em vez de refletir a distribuição geográfica dos proponentes. Isso enfraquece diretamente a descentralização geográfica e a capacidade de resistência à censura que poderíamos obter com um conjunto de validadores amplamente distribuídos globalmente.
Receitas: A latência média de processamento de blocos de ponta a ponta do Relé eficiente é de cerca de 5-20 milissegundos. Em seguida, há também uma latência de comunicação entre os construtores e proponentes. Ignorar o Relé reduzirá a latência, diminuirá o risco de execução interdomínios (por exemplo, CEX/DEX) e, por fim, aumentará as recompensas MEV dos proponentes.

TEE-Boost

Uma das principais propostas alternativas ao Relé é o "TEE-Boost", que depende de um ambiente de execução confiável (TEEs). É importante notar que TEEs não são o cerne da nossa solução; usar o TEE-Boost como um exemplo de ensino para o problema que estamos tentando resolver é útil.

Especificamente, o TEE-Boost exige que os construtores usem TEEs para criar provas, demonstrando a honestidade de seus lances e a validade do Bloco para os proponentes, sem revelar o conteúdo real do Bloco. Os proponentes podem verificar essas provas em hardware comum, sem precisar executar os TEEs por si próprios.

No entanto, o TEE-Boost tem um problema de disponibilidade de dados: os construtores apenas partilham provas TEE e cabeçalhos de Bloco com os proponentes, mas não partilham o conteúdo real do Bloco[1], e pode optar por não lançar o conteúdo do Bloco após o proponente assinar a cabeça (por exemplo, se as condições de mercado mudarem adversamente). As sugestões para resolver este problema de disponibilidade de dados incluem:

TEE Custódia: A TEE Custódia obtém o Bloco do construtor antes da assinatura do proponente e libera o Bloco após ver o cabeçalho de assinatura.

Camada de disponibilidade de dados: Os construtores publicam a carga do Bloco de encriptação na camada de disponibilidade de dados (DA).

Ambos os métodos têm desvantagens. A solução de custódia TEE replica a latência dinâmica centralizada semelhante ao Relé existente.[2]。Se usar uma camada externa de DA, serão introduzidas suposições de protocolo adicionais e suportada a latência dinâmica desse protocolo externo (que também pode ser desvantajosa).

Em teoria, se o proponente também tiver acesso ao TEE, o construtor pode encriptar o Bloco para ser executado no TEE do proponente. O TEE do proponente só descriptografa o Bloco após a assinatura. No entanto, acreditamos que o TEE-Boost não considerou esse design, pois isso exigiria que os validadores executassem TEEs. Esperamos que os validadores possam ser executados em hardware comum. [↩] (https://www.paradigm.xyz/2024/10/removing-the-relays#fn-ref-TEE-Boost)
Se o proponente operar o TEE-保管 como uma execução lateral compartilhada com seus validadoresNó, ele pode evitar a latência dinâmica

No entanto, também não queremos que os validadores executem TEEs. ↩

A criptografia de limiar para realizar a privacidade do construtor

Nós apresentamos uma solução elegante para lidar com o problema de disponibilidade de dados do TEE-Boost: encriptação de limiar para o comité de validação. Em particular, os construtores irão encriptar em limiar o Bloco para o comité de validação na proporção especificada para esse timeslot. Assim que forem recolhidas credenciais suficientes, o Bloco pode ser desencriptado e tornar-se disponível.

A tecnologia central ativada é a encriptação de limiar silencioso. Esta tecnologia criptográfica permite a encriptação de limiar sem a necessidade de construir previamente a fase de configuração interativa distribuída de geração de chaves secretas (DKG) necessárias. Em vez disso, a chave pública conjunta é calculada de forma determinística com base nas chaves públicas BLS existentes dos validadores e em algumas 'dicas' (discutidas posteriormente).

Isso permite comunicações diretas de salto único entre construtores e validadores com privacidade criptográfica. Os validadores não precisam executar suas próprias TEEs ou gerenciar nenhum material de Chave Secreta novo.

Mecanismo:

O construtor constrói um Bloco e o encripta para o comité de validação.

O construtor cria uma prova TEE para comprovar três aspectos ao comitê de validação: o lance é honesto, o Bloco é válido e a encriptação está correta.

Os construtores transmitem ao proponente um bloco de encriptação de limiar e uma prova TEE (incluindo o valor da oferta).[3]

O proponente assina o Bloco vencedor de encriptação e transmite a proposta para o conjunto de validadores.

Uma vez que um comité de verificação, com uma proporção designada (por exemplo, n/2 ou 2n/3), autentica o Bloco, este será desencriptado.

O Bloco descriptografado será confirmado normalmente.

O impacto das necessidades de largura de banda do proponente precisa ser estudado. Os proponentes de baixa largura de banda podem limitar as suas necessidades através da validação de prova do Bloco antes da solicitação do corpo principal, ou adotando outras técnicas de filtragem heurística e download inteligente. Este é um problema em aberto, mas parece não ser mais difícil de resolver do que o problema normal de propagação de lixo na pool de memória.

Nota

Desempenho

As características de desempenho do limite de silêncio encriptação são bastante favoráveis. Aqui, n é o tamanho máximo do comitê que desejamos suportar, t é o limite de descriptografia.

A encriptação e a desencriptação parcial são ambas operações de tempo constante. Com uma implementação simples, a encriptação leva menos de 7 milissegundos e pode ser paralelizada. A desencriptação parcial leva menos de 1 milissegundo.

Texto cifrado大小比Plaintext大768字节，这是一个常量附加因素（对于任何n和t）。

A descriptografia parcial da agregação (ou seja, a descriptografia) depende do tamanho do comitê. Quando n = 1024, a implementação simples leva menos de 200 milissegundos. Esperamos que, quando n = 128 (o tamanho do comitê de autenticação por slot), este tempo seja reduzido em um fator de 10 e a implementação possa ser ainda mais otimizada.

Importante é que o tempo de encriptação é um indicador de desempenho chave em comparação com a latência do Relé. Este é o conteúdo que os construtores devem calcular no "caminho crítico" gerado pelo Bloco. Este tempo é inferior à latência de processamento de Bloco existente do Relé e evita comunicações de vários saltos.

Publicação de dados

A encriptação do limiar silencioso não é totalmente gratuita. Na verdade, requer uma string de referência comum, na forma de: (g, gτ, gτ², …, gτⁿ⁻ᵗ), semelhante ao usado no esquema de compromisso polinomial KZG.

Além disso, cada validador com uma Chave pública BLS no formato g⁽ˢᵏ⁾ publica um conjunto de elementos de grupo que chamamos de 'dicas': (g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ). Essas dicas só são necessárias ao agregação da chave pública e decifração de texto cifrado. A encriptação usa apenas uma chave pública agregada de tamanho constante.

At the time of writing, there are approximately 1 million validadores. If we set n=128 and t=n/2, each validadores needs to publish approximately 3KB of hints. Therefore, storing all the hints of the validadores requires 3GB of space.

Com a ativação do MaxEB, esse requisito pode ser significativamente reduzido, permitindo que validadores MaxEB permite mantenham um saldo maior do que 32 ETH sob a mesma Chave Secreta (em vez de distribuí-lo em vários depósitos de 32 ETH). A redução do conjunto de validadores a ser implementada ainda está em discussão. Podemos chegar a cerca de 1GB.

Finalmente, de acordo com as futuras mudanças na arquitetura Ethereum Consenso (por exemplo, a redução adicional do tamanho da validadores ou a substituição da linha de finalidade), o tamanho das dicas a serem armazenadas pode diminuir ainda mais.

Vitalidade

O Ethéter Bloco espera manter-se online mesmo em condições de rede desfavoráveis. Um problema deste esquema é que, devido ao comitê especificado estar offline, podem ocorrer Blocos que não podem ser descriptografados.

Uma solução é permitir que os construtores decidam a proporção de comitê aceitável (t) a ser usada para descriptografia. Existe um equilíbrio entre a privacidade (possibilidade de descompactar e roubar MEV) e a probabilidade do limiar do comitê. Para os construtores, maximizar a inclusão dos seus Blocos na cadeia, em vez de serem forquilhados, maximiza os ganhos, então eles devem encontrar uma configuração de limiar otimizada.[4]

Além disso, o uso deste esquema de encriptação deve ser uma escolha voluntária. Em condições de rede desfavoráveis, se não houver nenhum comitê de escala aceitável disponível continuamente online, os proponentes e construtores podem recorrer ao uso de Relé, construção própria ou outros mecanismos escolhidos com base na natureza desfavorável do ambiente.

Especificamente, o valor esperado do Bloco do construtor que é bifurcado é negativo (eles não recebem receita dele), e o valor esperado do desbloqueio é muito negativo. Se os construtores forem incentivados a escolher t entre [0, 128], eles devem naturalmente escolher um t suficientemente alto para aumentar o risco de desbloqueio e aumentar a probabilidade de satisfação (pelo menos t membros do comitê online). Sob condições normais de rede, alguns Blocos podem ser bifurcados, mas observamos que isso já aconteceu no jogo de tempo e a atividade da cadeia ainda é aceitável. [↩] (https://www.paradigm.xyz/2024/10/removing-the-relays#fn-ref-Liveness)

Blocos indisponíveis

Além disso, o comitê pode estar online, mas os construtores podem ser capazes de criar uma situação em que o Bloco não pode ser descriptografado ou é inválido ao ser descriptografado (por exemplo, usando prova fraudulenta).

Do ponto de vista do protocolo, é possível descartar esses blocos bifurcados. Um conjunto mais amplo de validadores simplesmente não pode provar esses blocos ou qualquer bloco que os referencie. A melhor maneira de lidar com esse erro provavelmente seria fazer com que o cliente de consenso esteja ciente dessa possibilidade e seja capaz de falhar elegantemente. Isso requer mais pesquisa.

Estrutura de mercado

Os construtores vencedores sabem o conteúdo do Bloco antes de atingirem o limiar, o que pode resultar em uma vantagem injusta em períodos posteriores. No entanto, o comitê de prova deve agir antes do final do próximo período, uma vez que a maior parte do valor do Bloco é concentrada no final do período, de modo que o impacto dessa vantagem deve ser minimizado o máximo possível.

Prova de Criptografia Pura

A longo prazo, pode haver a oportunidade de substituir a prova de conhecimento zero (zk-SNARKs) pela prova de execução confidencial (TEE). Atualmente, a zk-SNARKs é muito lenta, mas avanços em criptografia, software e hardware especializado (ASICs) podem eventualmente tornar a geração de zk-SNARKs viável dentro das limitações de latência necessárias. É digno de nota que a zk-SNARKs acompanhando o Bloco já é parte fundamental do longo prazo do Ethereum.

Usando

Com base no tamanho atual e na taxa de crescimento do conjunto de validadores, essa solução pode não valer a pena em termos de volume de dados necessários para serem publicados na L1. No entanto, a Ethereum já planejou reduzir significativamente o número de validadores por meio do MaxEB.

A melhor maneira pode ser atualizar antes ou depois do MaxEB, para que o cliente de Consenso possa estar ciente da possibilidade de encriptação de blocos e incentivar os validadores a publicarem dicas. Por exemplo, após o MaxEB, pode-se exigir que os novos validadores adicionados publiquem dicas, enquanto os antigos validadores podem receber incentivos para atualizar.

Assim que um número suficiente de validadores adotar esse mecanismo, os construtores começarão a usá-lo para garantir o tamanho adequado do comitê (ou seja, equilibrando a privacidade e a possibilidade de descriptografia).

Se o nosso método for realmente superior em termos de latência do que o encaminhamento de múltiplos saltos, o mercado deve adotá-lo espontaneamente, sem a necessidade de protocolo forçar o uso ou especificar configurações de parâmetro específicas.

Princípio Básico

Relé é uma das fontes centralizadas mais importantes do Ethereum, resultando em oportunidades de locação e distorcendo a descentralização geográfica do protocolo. Precisamos remover o Relé e considerar isso como uma solução relativamente elegante. Isso exigirá mudanças no nível de consenso, mas os validadores não precisarão fornecer novo hardware ou materiais de Chave Secreta.

A desvantagem é que é uma mudança complexa na camada de consenso, e esse mecanismo (se adotado seletivamente, conforme sugerido) pode ou não ser aceito pelo mercado. No entanto, muitas mudanças potenciais nos canais de MEV também enfrentam problemas semelhantes de adoção e otimização de lucros (por exemplo, incluindo a lista). Além disso, no futuro, pode haver outros casos de uso que dependam de um conjunto de validadores com infraestrutura de encriptação de limiar.

Declaração:

Este artigo é reproduzido de[paradigm], the copyright belongs to the original author [Charlie NoyesGuru, Vamsi Policharla], if there is any objection to the reprint, please contact the Gate Learn team, the team will handle it as soon as possible according to the relevant process.
Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo representam apenas a opinião pessoal do autor e não constituem qualquer tipo de conselho de investimento.
As outras versões linguísticas do artigo são traduzidas pela equipe do Gate Learn e não podem ser copiadas, divulgadas ou plagiadas sem mencionar [Gate.io].